找救援

意識到有問題時，首先尋找有沒有專案遇到同樣的問題——有使用 Ruby on Rails 的大規模專案不少，那為何不會浮現這些問題，代表我們肯定是有哪個環節需要修正，但每個專案的情境和需求都大相逕庭，因此沒有甚麼進展。

因緣際會下，同事麥可認識了領域驅動開發(Domain-Driven Design，後簡稱 DDD)，並認為我們可以試著遵循裡面的原則套用在專案，理由有以下幾點:

• 領域知識龐大，細節眾多
  單獨一人幾乎不可能掌握領域中所有的細節，而 DDD 可以專注在業務邏輯，並讓程式碼更容易被測試，使開發人員可以在短時間透過測試了解領域知識。
• 需求一直在變
  DDD 可以讓程式更好的模組化，而更好的模組化代表開發時更彈性，有效應付持續變動的需求。
• 領域知識複雜
  透過 DDD 的戰略設計可以使業務人員更好地理解自己的需求，並讓開發人員與業務人員有效的溝通，避免雞同鴨講。

決定要導入 DDD 後，首先是先整理目前的狀況

第一步

一開始我們先做了兩件事

• 分析現有系統，並嘗試切割出不同領域
  我們先印出 DB 中的 er-diagram 和列出網站大致上的所有功能，接著嘗試把我們認為是同一個領域的 model 圈在一起，其中也會有出現不同領域共用同一個 model 的情況。

• 在核心領域(core domain)中找尋共通語言與領域事件
  透過目前的程式碼和到處詢問相關部門的人員，收斂領域知識。這邊比較有系統的做法可以透過 事件風暴 (Event storming) 的方式來實踐。

  關於事件風暴可以看這系列的文章，有詳細的解釋
  Event Storming Part 1 - 簡介與事前準備

Q: 要怎麼知道這樣切割的領域是對的?

專案一開始如果視為一個大領域，不管怎麼切都可以減少需要關注的邏輯，因此對我們來說這樣的改動方向是對的。
當時我們的想法是，先透過既有程式碼和腦中舊有的知識大致規劃出一個雛形，這樣的切法肯定不會是最完美的，但至少能降低每個領域的複雜度，收斂各領域的知識並為其建立知識庫和測試，而有了測試，要再把領域切更細或是把多個領域合併成一個都會比較輕鬆。
除此之外，每個領域的設計其實會對應到我們對該領域的認識，而切分領域會使我們更專注在業務邏輯上，這也使我們更容易對領域去做更深的認識。
我認為切割領域是一種持續循環的調整，因此只需要滿足當前的需求就可以有效地解決問題，當新需求進來時，如果目前的設計導致開發成本過高，代表有新的領域知識，需要重新調整領域。

後記

一開始踏入 DDD 是透過閱讀 Eric Evans 所撰寫的領域驅動設計，老實說到現在仍有許多地方沒有理解的很透徹，直接閱讀本書會有許多新的觀點，但比較可惜的是這本書對如何實作 DDD 的方法著墨較少，所以後來都把這本書當作靈感書來使用，當有想不通的地方回去翻翻通常都會有新發現。